Just going to boil it down to the main components, so skinning can be added later.

You should probably break this PR up into different components instead of just having 1 big PR that is essentially adding "Rewind" to replays.

I think the only part where it would make sense to split up is between the base analysis settings implementation and the osu!std analysis implementation, but I don't know that it's really necessary to do that.

maybe I'm biased from circleguard but I think crosses look better than plusses for hit markers, going off the linked video. afaik rewind does crosses as well

I initially did a cross design to match rewind, but I think the difference in using a plus is negligible. As peppy mentioned in his review, it could be confusing to use a cross since that design represents a miss.

I've done an initial visual pass, open to feedback.

Not a super big fan of the alternating colors either, it feels like they should match the corresponding judgement rather than being entirely separate.

Disagree, it's useful to see the different keys for identifying issues such as a weaker finger

(haven't built myself, going off @dani211e's video (thanks!)) -

• circle markers are a big improvement over the plusses or even crosses
• the cursor trail seems quite long. I made this configurable in circleguard and by default it was ~3/5 that length. It should probably roughly match the fadeout of the hitobjects? I don't expect this to be configurable off the bat, though it may be nice.
• I'm personally not a big fan of coloring the markers based off the keypress, only because there's no intuitive mapping f: color |-> keypress. What is blue? what is yellow? do they even correspond to keypresses? I'd figure it out after a while, but corresponding to judgments is much more intuitive. I know we dislike toggles over here, but maybe this one really should be a toggle, defaulting to judgment. fwiw I never colored the hit markers in circleguard, though I got quite a few requests for it, so it's clearly something people want.

@Sheppsu one other issue i'm not going to fix in this PR is that rewinding draws previous frames in front of newer ones rather than behind. maybe something you can add to the todo list.

@Sheppsu one other issue i'm not going to fix in this PR is that rewinding draws previous frames in front of newer ones rather than behind. maybe something you can add to the todo list.

Ah ok, I'll look into that for a follow-up.

I'm going to lock in these visuals for now after one too many passes:

Fix seems fine, thanks.